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Prior Disclosure 

[Has there been any disclosure of the invention outside of Microsoft? If so, please identify the party (or parties) to whom disclosed, 
as well as the date and circutnstances under which the disclosure was made (signed/unsigned non-disclosure agreement, etc.). 
Disclosure may include such things as an offer for .sale, a demonstration, or a publication describing a novel aspect of the 
invention./ 

There had been no outside disclosure. 
Introduction 

[Please provide a high level description of the invention, including the names of the people who contributed to the invention.} 

The invention is an HTTP based reliable messaging protocol to enable bi-directional reliable messaging 
through a Web Proxy Server. 

HTTP is a request-response protocol in which all data exchanges are always initiated by a web client. This 
is true for direct client to server connections and indirect connections facilitated by a Web Proxy Server. 
The HTTP protocol directs that the Web Client sends a request to the Web Server, and the Web Server 
replies to the Client. 

The Web Proxy Protocol is such that client sends a request to the web proxy, it forwards it to the web server 
and in reply the web server sends the Web Proxy a response to that request, which the Web Proxy relays to 
the client. 

Due to that limitation, communication protocols built on to of HTTP. do not allow a web server to send 
unsolicited data to the client (unsolicited data is data that is not sent as a reply to a client's request). 
The proposed protocol enables the sending of bi-directional unsolicited messages a web proxy server 
through the use of 2 client-initiated virtual channels. One channel is for client-to-server communication and 
server message-delivery acknowledgments. The other is for server-to-client communication and client 
message-delivery acknowledgments. 

Strategic Importance of Invention: 

[ Please provide reasons why you think patent protection for this invention is important to Microsoft. Factors to consider include 
(I) is it core technology: (2) is it a feature that gives Microsoft a competitive advantage: (3) is it a feature that our competitors 
would want to copy; (4) does it include new APIs, file formats, network protocols, data schema or other components relating to 
product interoperability ( 5) is it related to a standard. Please include who you consider the most likely competitors and/or 
competitive products for this technology.] 

It is a core technology for reliable Internet messaging, since it enables clients to receive and send messages 
in an efficient manner, without the need for any facilitating communication to allow the server to send 
messages to the client (such as periodically querying the server for messages). 

It gives Microsoft a competitive advantage since it allows our messaging system to be more efficient with 
regards to network u-affic and it is likely to be copied by any HTTP based bi-directional messaging system. 
This is a new HTTP based protocol and it defines communication patterns, HTTP message formats and data" 
structures. 

Possible competitors may include IBM's MQSeries messaging middleware (http://www.ibm.com/mqseries), 
Tibco's Rendezvous and other technologies (http://www.tibco.com) and CityNet's RTTP protocol based 
offerings (http://citynet.uk.com). 

Motivation for the Invention: 

[ Describe (I) the problem addressed by the invention (e.g., limitations of prior products of Microsoft, or others), and (2) your 
solution to the problem (including what "new" things your invention does and a high-level description of how it does them).} 
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The motivation for this invention was the need to introduce Internet capabilities to our MSMQ messaging 
solution. 

MSMQ is an enterprise messaging solution and as such it assumes that (a) senders and receivers are 
symmetrical in their capabilities, and that (b) there is seamless direct connectivity between senders and 
receivers. 

Moving onto the Internet MSMQ encounters connectivity problems, such as the need to go pass Web 
Proxies. Web Proxies mandate the use of HTTP as an enabling protocol on top of which higher-level 
protocols can be built» and creates a setting in which the sender and receiver do not have the same 
capabilities. Namely, the Internet deployed party cannot directly and without assistance send messages to 
the party behind the corporate firewall. This changes the model from peer-to-peer communication to client- 
server communication. 

Description of the Invention: 

[Describe your proposed implementation of the invention, including the architecture and design details of the implementation. The 
design details should include a description of the component parts of, and individual operations performed by, your 
implementation. The use of a specific example, showing how the invention solves the problem being addressed, can be particularly 
helpful. You should also mention whether you have thought of any other implementations, or applications of, your invention. In 
most cases. J -2 pages of description should be adequate to start the patent application process, although a more detailed 
description may greatly enhance the efficiency of the process.] 

The proposed protocol enables the sending of bi-directional unsolicited messages via a Web Proxy Server 
through the use of one (1) or two (2) client-initiated virtual channels. 

Connection Policy 

When the client wishes to engage in bi-directional messaging with the server it opens two virtual channels, 
one for incoming traffic and one for outgoing traffic. Bi-directional messaging is the common case, but the 
client may choose to open only the incoming or outgoing channels. The client has sole responsibility when 
it comes to establishing and maintaining the connections, including but not limited to the reconnection 
policy and the channels it wishes to establish. This protects the client from unwanted traffic, and gives him 
control of network usage and cost. For example, some users may have per-minute connection fees and will 
most likely wish to minimize the time they are connected. Those users would prefer to work in bursts of 
communication, as opposed to message trickle. Administrators of large networks would may prefer network 
users to work in trickle mode, since that gives better network load distribution and helps prevent temporal 
network congestions. 

Outbound Communication 

The outgoing channel is intended for client-to-server messaging and server message-delivery 
acknowledgments. This channel uses the ordinary HTTP message pattern. The client sends the server a 
message in the format of an HTTP request, and the server replies in the format of an HTTP reply with a 
delivery or non-delivery acknowledgement. The server may ask for retransmission of this message or 
previous messages, and in cases where a reply is required it may provide the client with hints as to when a 
reply for that message will be available. The client may decide when and if to use any hints provided by the 
server. For example, the client may use this information and the reconnection policy to determine when it 
needs to open an inbound channel with the server. 

Inbound Communication 

The incoming channel is for server-to-client communication and client message-delivery acknowledgments. 
This channel uses a messaging pattern that is reversed to the HTTP communication pattern. When the client 
initiates this connection, it parks an HTTP request at the server. That request enables the sender to reply to 
the client. When the server has a message to be delivered, it will send an HTTP reply to that request, and 
embody the message in the reply. The client will in response to that message send a delivery 
acknowledgment as an HTTP request, and that acknowledgment will act as the parked request to which the 
server may respond with the next message it wishes to send. 
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Network State Detection and Session Reconnection 

Messaging on the Internet is subject to varying network conditions. Connections may be brought down, 
different networking layers may time-out in cases where no data flows through them for prolonged periods 
of time, servers may become unavailable, and so on. In the event where the client and server connections 
are severed, it is up to the client to detect that state and try to reconnect to the server. The protocol defines 
the mechanism to assist that detection and facilitate the transmission or retransmission of messages sent 
during the disconnection period. 

Message Exchange Patterns 

This protocol allows different message interaction patterns, including but not limited to single sided client 
messages, single sided server messages bi-directional message exchange and conversation. A conversation 
is a series of message exchanges thai are related to one another. The protocol doesn't limit the kind or 
number of message exchange patterns that can occur concurrently, for example, different conversations may 
be held at the same time using the same virtual sessions. 

Diagrams and Flow Charts: 

(To support the description provided above, please include: (a) at least one block diagram showing the architecture of the system 
tliat implements your invention, and (b)at least one diagram illustrating the primary steps performed by your invention.} 



System Overview 
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Message Exchange Pattern - Outbound Connections 



Client 



Web Proxv 



Client sends an HTTP request 
with the message body 



Proxy returns the reply 



Server 



Proxy forwards the request 



Server sends an HTTP reply with 
the message acknowledgment 
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Message Exchange Pattern - Inbound Connections 



Client 



Web Proxy 



Client sends an HTTP "request" 
(asking for messages) 



Proxy returns the message 



Client sends an HTTP "request" 
with the message 
acknowledgment 



Server 



Proxy forwards the "request" 



Server sends an HTTP "reply" with 
the message body 



Proxy forwards the 
acknowledgment 
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Additional Information: 

• List the names of any people who contributed to the invention. 
Shy Cohen 



List any earlier, current or anticipated MS products that may use your invention: 
A future version or the successor of MSMQ 



List and attach (or provide pointers to) any documents that provide additional information about your invention or the 
product to which it relates, including specifications, journal articles, slide presentations, test/performance results, etc.] 

Note: This is a functional spec draft - the specified protocol was removed from future versions of this document. 
\\shvdevT\docs\firewalls protocols functional spec OOOJ27.doc 



List any other sources that would provide helpful background information or illustrate prior work of others in this area 
(including, e.g., journal articles, textbooks, product literature, products, and specifications): 



RFC2616-HTTPL1 / 
Microsoft MSMQ 
CityNet's RTTP 
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